: I would be very grateful if anyone could answer some or all of these questions.
: What are the results of mixing multicolor and extended color mode when using a text screen? If they don't mix which bit has the priority? Does the extended color bit by it's self have any effect at all in bitmap mode? Is there any useful effect from setting both the multicolor and extended color bits in bitmap mode?
If you combine the extended colour mode with a multicolour or high resolution mode, the screen becomes black. The sprites are still visible, and the border colour is not affected by this effect, but there is no text or bitmap at all. Some C64 games which need a split screen (for example GRIBBLY'S DAY OUT and AIRWOLF) use this effect to separate both parts of the screen by some black scan lines: They start mixing extended colour mode and multicolour/bitmap mode at, for example, scan line 200 and return to normal operation an scan line 207, thus producing eight black lines which separate the playing field from the scores display.
: When using the raster interrupt does the interrupt occur at the beginning of the scan or the end or does it happen about xx cycles into the scan?
It is very difficult to check this out by software, because the 6510 CPU always needs some time to handle the IRQ, but it looks like the IRQ occurs at the beginning of the scan line.
: When you have set the interrupt latch will you get an interrupt only once or every time the VIC scans that line?
You get an IRQ every time the VIC reaches this line.
: If you set the MSB of the interrupt latch what value is used for the lower bits, is it the last value entered or the next one? There after must you clear the MSB if you want a lower value interrupt or does it clear automatically?
The MSB and the lower bits are completely independent; so setting or clearing the MSB does not affect the lower bits. Especially, when your interrupt latch contains a value between 56 and 255, setting the MSB will result in an interrupt latch value in the range of 312..511 - that means that you won't get any interrupt requests at all (see next question). Vice versa, the MSB has to be cleared if you want a lower value interrupt.
: From my understanding the VIC's visible scan lines are from $32 to $F9 inclusive are these are these values correct? What is the last scan line before the VIC wraps? Does it wrap to $0 or $1?
The values $32 (50) to $F9 (249) are correct. The VIC wraps to $000; scan lines reach from $000 (0) to $137 (311). Each scan line needs $3F (63) CPU ticks to be displayed; the resulting screen refresh rate is 985248 Hz / (63 microseconds * 312 scan lines) = 50.125 Hz (PAL version).
---------------------------------
Z80 in 128
From : brmcf@utkux1.utk.edu
I didn't save the z80 in a 128 discussion, so I can't quote it directly. However, I noticed two things that I've run across before:
(a) How fast is the Z80? Its 2MHz in 80 column mode, and how would you get anything done in 40-column mode in the first place? Sure, its in there, but its not supported by software the same way the C64 40-column mode is. The chip is *rated* to go faster, but Commodore didn't get around to making it run at a respectable speed. I've read complaints about this on comp.sys.cpm.
(b) Why does the Z80 take more cycles to do something? The pipelining the 6502 does isn't that big a deal: it executes the last cycle of an instruction while performing the fetch of the next instruction, so it (in most cases) removes only one clock tick, and in others (if the last instruction required a memory access) it doesn't change any timings. The difference is that the Z80 (and its 16-bit big brother the 8086) perform some internal operations a piece at a time, with cycles for internal operations seperating memory accesses. The 6502 (and its 16-bit big brother the 65816) perform all internal operations in one clock. So if the instruction is to LDA 34562,X, the 6502 gets the instruction (one tick) gets the low byte of the address (two ticks) gets the high byte (three ticks) reads the unindexed address while it performs the index (four ticks) reads the indexed address (five ticks). So you can see why indexed instructions take an extra clock when they cross a page boundary: there is literally no time in 5 clock ticks to increment the high byte of the indexed address if there was a carry.
(c) If the 6502 is more efficient, why does the Z80 have a reputation for being faster for 16-bit instructions? Well, look at the above: three clocks to read the instruction, one or two to perform the indexing, and one to execute the instruction. The instruction reading overhead is 50% to 60% of the execution time. Both the Z80 and the 6502 do 16-bit instruction a byte at a time, but for the Z80 these can be single instructions, while for the 6502 several instructions are required. Obviously, if you combined the efficiencies of the 6502 instruction execution with internal 16-bit code, and make it run faster, you'd have a chip that would smoke a Z80. That's the 65816 -- unfortunately by that time the competition was the 68000 and 8086.
-------------------
From : 621126@mercury.utb.edu
NEUS@timsg.csc.ti.com (Mike Neus) said :
The 128 programmers referance guide explains it all. The Z80 is indeed clocked at 4MHz, but to enable the 40 column screen, the clock is stopped every two cylces (when phi-2 is low?). This reduces the speed of the Z80 to 2MHz. On top of this is the VIC DMA's, which slows the Z80 further. Turn the VIC off as a display chip and you probably will get 2MHz. I'm not sure if the clock streching cripple applies to the Z80 when it accesses I/O, but I don't think so.
-------
I have turned off VIC-II (using CONF in CP/M), I even put in a new BIOS that eliminates all calls to the 40 col screen from within CP/M. You would THINK I'd be able to get a semblance of 2 Mhz out of the Z80 B, referred to by the 128 PRG as a Z80 A. On a bit of trivia, Zilog tells us that Z80 B's are rated for 6 Mhz, but C= is C= and well, let's move on;
I've been sent variations on the above, different interpretations drawn from the 128 PRG and other sources. However, I did find the following variation interesting, and I hope the authors don't mind me recanting it here.
Below a mail I sent Jopi where I was commenting something you have quoted. There you can read the technical explanation why the sucker is so slow.
Hello Jopi!
>On chip level, there are 4 latches/bus drivers to syncronise the data transfer. The Z80 itself is halted (remember the peculiar clock signal) while I/O is used.
Why is the Z80 supposed to be halted while I/O is used? Take a look at the C128 schematic part C128-1O.TIF. The Z80's data driver U12 is clocked with 1MHz anyway. So ANY read operation is aligned to the 1MHz boundary, there must not be an extra handling of Z80 I/O in terms of timing. It's just like any memory access, but with different PLA banking so the RAM address space is not polluted.
As this 1MHz line is also connected to the SID, it is uncheatable by the VIC-IIe otherwise the sound would be a bit strange. That means the entire Z80's bandwidth is stripped down to maximal 1MB per second all the time just like the 8502 in 1MHz mode. No 2MHz bandwidth mode for Zilog!
Or do you meant with "I/O" external accesses of the Z80 in general? (I'm a bit confused since the Z80 knows I/O accesses and memory accesses and I'm not sure whether you meant I/O access only or both)
But this is not so important since I think the Z80 is not halted on any access either, making it regardless what you meant. :-)
The reason why I think so is the Z80's -RD line. With this line the Z80 can read the bus anytime it wants. As this line is not connected to anything else than the latch the system MUST assume that any Z80 cycle is a read (or write) bus cycle as it can't determine if the Z80 really wants to read something or not!
Do you agree to this thesis or have you different thoughts?
Combining "1MHz bus cycles only!" and "any Z80 cycle is assumed to be a read (or write) bus cycle!" gives a very bad result. The clock must be around 1MHz - but they could used a bit fine-tuning. If I recall it right any Z80 memory access takes 3 Z80 cycles, so they can split 3 cycles into 2 1MHz timing slots and they still would not violate the 1MHz read access boundary. So the real PHI-Z80 might be 3/2*1MHz = 1,5MHz. That's all.
Even 1,5MHz is pretty slow. But what can we expect from people who used to mess around with synchronous CPUs like the 6502 - they just treat any other CPU the same way, even if it is the wrong one. Someone here showed that with an asynchronous interface of one single TTL+latches a Z80 can be hooked onto the C64's memory bus. It is also limited to 1MHz bandwidth, but his Z80 could operate at ANY frequency the Z80 can do, up to 6MHz.
> Note that e.g. I/O is harder (and slower) to access from Z80.
It is harder and slower due to the OUT/IN commands but not due to external timing things. It is clocked slow enough. :-)
---------------------
c64 cross assembler?
From : Gaelyne Moranec
Quote text forwarded from the (Australian) <64TALK> conference.
G'day all,
I thought some of you might be interested in this:
--- Text Import Start ---------
c64 cross assembler?
From : Errol Smith
To : Rod Gasson
G'day Rod,
ES> What I wanna know is, are there any cross assemblers for the c64 that work from a PC,
RG> Yeah, there's at least half a dozen of them.
ES> and if so where do I get them?! (:
Couldn't find one with keyword searches, but I managed to get my hands on a simtel cd-rom, and found about 7 or 8 6502 assemblers that work on a pc.
RG> The one I use is called TASM. I got it from Compu$erve, but you should be able to locate a copy on fido BBS's.
Yep, I've heard of that one before. It's what you use for QWKRR128 is it not? Is it the better out of what you found (or just better for you in particular?)
Just for your (and anyone elses) interest, here is what the simtel cd had to offer:
AS65
108.ZIP - 6502/65sc02
ASSEMBLR.ZIP - generic 6502/6803/8085
PS65A12.ZIP - 'PseudoSam' - 6502
SVASM02.ZIP - 6502/65c02
TASM276.ZIP - many cpus (including 6502 obviously)
XASM220.ZIP - ""
And lying around some bbs I managed to find:
C64ASM.ZIP - c64 specific, but I can't see why it wouldnt work on a
128 (or any other 6502 machine). The only 64 specific
things are basically header files etc. It also includes a
simple disassembler.
I haven't given them much of a lookover yet, but not many are macro-assemblers, and just about all of them seem to have a different input and/or output file format..
Ok next question, what (if any) C compilers exist for the 64/128, are they still supported, how ANSI C compliant are they, are they commercial/shareware/PD, is the source available for any of them? (that should keep you (or anyone else) busy (: )
My curiosity has been sparked after seeing comments in the cbm echo that the main reason 64/128 versions of zip/unzip 2.xx (and many other utils I would assume) don't exist is because of the lack of a C compiler to create them with (at least that was the gist I got).
I've had a bit of a hunt around for C compilers that could be modified to create 6502 code. I couldn't find any that already made 6502 code unfortunately.. :( The only 2 I've found so far are 'Small-C' - it's free (with source code), but no documention, which apparently originally came from a book. Even the latest versions are not very ansi c compliant.. (lack a lot of things basically).
The other is 'Micro C', which is a shareware (more like commercial) package which you have to purchase to get the source code. It supposedly is written from the ground up for 8 or 16 bit systems, and the compiler can apparently run in around 32k memory. It comes with lots of documentation on porting it to other systems. Ports currently exist for 68HC08, 6809, 68HC11, 68HC16, 8051/52, 8080/85, 8086 & 8096. It also is much more C compliant than the small-c compiler.
I'm no cpu master, so I'm not sure how many of the above are 8bit systems, or even if some of their cpus are supersets of the 6502 (would be nice). The only con for micro-c is the price, at least US$100. It's not very clear in the catalog as to what you'd actually need, so you could end up needing more 'add-ons', which could push the price higher than that.. (US$150+).
Get your hands on MC310PC1.ZIP for the micro-c, or SMALLC22.ZIP for small-c if you want to check them out yourself.
It would certainly be an interesting challenge, but I dont think I'm quite up for spending maybe A$200 on something that may be completely useless (ie. porting could be impossible).
